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(57) Abstract: A receiver for receiving packet data from a transmitter, the transmitter and the method of controlling transmission. 
The receiver may comprise first detection means for detecting that its memory has enough space to store a data packet and flow 
control signal means for providing a flow control signal, preferably a first flow control signal, to the transmitter in response to said 
first detection means. The receiver may comprise second detection means for detecting when a first portion of a packet has been 
received from the transmitter and flow control signal means for providing a second flow control signal to the transmitter in response 
to said second detection means. The transmitter may comprise third detection means for detecting the second flow control signal 
sent by the receiver and packetwise transmission means arranged, responsive to the third detection means, to complete transmission 
of a partially transmitted packet and then to stop transmission of further packets. 
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Asynchronous Serial Data Interface 

This invention relates to a serial communication system with data flow 
on a cable. e.g. a Universal Asynchronous Receiver / Transmitter (UART). The 
data is packet data. 

A UART has a data connector connecting a transmitter to a receiver. The 
data sent from the transmitter to the receiver may be packet data. A packet is 
made up of multiple bytes of data. When the transmitter is sending packets 
asynchronously to the receiver it is important for the receiver to know where 
one packet ends and the next packet begins. 

It is known for the receiver to count received bits/bytes from the start of 
co m mu n ication. The first data bytes the receiver receives then must be the 
start of a packet. The receiver knows length information about the packet, and 
from this information the receiver can calculate when the end of the packet is 
received. Consequently, the next bytes it receives must be the start of the next 
packet. Thus the transmitter and receiver remain synchronised at the packet 
level. 

Now, if an unknown number of bytes is lost because they don't fit in the 
receive buffer any more ("buffer overflow") the receiver loses packet 
synchronisation, i.e. the knowledge about when the next packet begins. In 
order to prevent buffer overflow in the receiver a flow control mechanism is 
needed. 

A UART has a data connector connecting a Transmitter to a Receiver and 
a control connector connecting the transmitter and receiver. Data in bit serial 
format is transported from the transmitter to the receiver via the data 
connector. The control connector carries a control signal RTS/CTS which 
implements flow control from receiver to transmitter by indicating "flow on" 
(RTS/CTS active) or "flow off 1 (RTS/CTS inactive). Flow control prevents too 
much data being sent by the transmitter and causing overflow of the receiver 
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Bytes can get lost if the software in the receiver and the transmitter does not 
react fast enough to prevent buffer overflow. In this case packet 
synchronisation on the interface is lost. 

To overcome the problem of loss of synchronisation when software flow 
control is used, a "packet delimiting" mechanism has been used. Packets are 
preceded/followed by a certain pattern as a packet delimiter. However, there are 
certain problems because the same delimiting pattern may occur within the 
packet that shall be transmitted. This problem has been solved , for example, 
by the SLIP software protocol in which any occurrence of the delimiter in the 
data stream have to be replaced by "Escape sequences" . However, the software 
implementation of such a protocol is computationally intensive. 

Therefore when there is no hardware support for flow control, bytes can 
get lost if the software does not react fast enough to prevent buffer overflow 
and either a complex and computationally intensive software protocol is used 
to delimit the packets or packet synchronisation on the interface is lost. 

It would be desirable to provide an alternative flow control mechanism 
which provides packet synchronisation. 

It would be desirable to provide the mechanism in software with a very 
low processing cost. 

It would be desirable to provide the mechanism without altering the 
content or size of the packets. 

According to a first aspect of the present invention there is provided a 
receiver, for receiving packet data from a transmitter, comprising: an output for 
issuing flow control signals to the transmitter; an input for receiving data from 
the transmitter; a memory for storing data received from the transmitter; first 
detection means for detecting that the memory has enough space to store a 
data packet; and flow control signal means for providing a flow control signal 
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The flow control means provides a second flow control signal, stopping 
the transmitter from transmitting the next data packet, in response to the 
second detection means. 

The receiver may additionally comprise: first detection means for 
detecting that the memory has enough space to store the next packet to be 
received, wherein the flow control signal means provides a first flow control 
signal in dependence upon the first detection means. The first flow control 
signal enables the transmitter to transmit the next packet. 

According to this aspect of the present invention there is provided a 
method of controlling packet data transmission from a transmitter to a receiver 
by sending flow control signals from the receiver to the transmitter, comprising 
the steps of: sending a flow control signal for disabling further transmission of 
data packets, while a current packet is being received and in time to allow the 
transmitter software to respond thereto and to stop transmission before the 
beginning of the next packet is transmitted. 

The flow control signal is preferably a voltage transition The first and 
second signals are preferably complimentary signals. The first flow control 
signal preferably corresponds to a positive transition in RTS/CTS. The second 
flow control signal preferably corresponds to a negative transition in RTS/CTS. 

The packet may comprise a header and a payload. It may be of variable 
size. The header preferably identifies the packet size to the receiver. The 
receiver may have means for determining the start of a packet and means for 
counting the bits/bytes received from the start of a packet. The receiver may 
have means for reading the packet length of the current packet from a received 
header. 

According to the preferred embodiment, the first detection means may 
detect that the memory has enough space to store the next packet to be 
received, for each packet. The receiver may have means for reserving sufficient 
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Compared to the hardware protocol the invention prevents the hardware 
overhead. A significant advantage of embodiments of the present invention is 
that they can still be implemented when the hardware is fixed and cannot be 
changed. 

A current mobile phone may use an integrated circuit without hardware 
flow control on its I/O interface. As the integrated circuit is already being 
produced it is no longer possible to change the circuit and add hardware flow 
control. It would be particularly advantageous to be able to add a module to an 
existing mobile phone to enhance the phone's functions. One such module 
could be a Bluetooth transceiver. For such a module, it is imperative that 
packets of data can be transferred between module and phone without loosing 
packet synchronisation. Such transfer can be provided according to the present 
invention. 

A "general purpose 10 (input/output)" of the phone can be set by 
software (when being an output) or cause an interrupt on a level change (when 
being an input). One 10 may be used for RTS/CTS of reception, and one 10 may 
be used for RTS/CTS of transmission. 

Embodiments of the invention therefore also particularly relate to 
computer program products which may be added to a device to program the 
general purpose I/O and allow it to function as a transmitter and/or a receiver 
according to the invention. 

According to a further aspect of the present invention there is provided 
a computer program product which provides in a receiver having an input for 
receiving data, a memory for storing data and an output: first detection means 
for detecting that the memory has enough space to store a data packet and flow 
control signal means for providing a flow control signal at the output in 
response to the first detection means. 

According to another aspect of the present invention there is provided a 
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Figure 1 shows a system with a serial communication interface; 
Figure 2 shows the packet structure; and 
Figure 3 shows the signal timing of the protocol. 

Figure 1 illustrates a serial communication system 1 with packet data 
flow on a single cable, possibly in each direction. 

The system 1 has a Transmitter 30 and a Receiver 20 interconnected via 
interface 10. The interface has a data connector 12 connecting pin 32 of the 
transmitter to pin 22 of the receiver and has a control connector 14 connecting 
pin 24 of the receiver to pin 34 of the transmitter. Data in bit serial format is 
transported from the transmitter to the receiver via pin 32, the data connector 
12 and pin 22. The control connector 14 carries a control signal RTS/CTS 
asserted on pin 24 of the receiver. The control signal implements flow control 
from receiver to transmitter by indicating "flow on" (RTS/CTS active) or "flow 
off" (RTS/CTS inactive). Thus data transmission from left to right with flow 
control can be achieved. 

If data transmission from right to left is required, device 20 can acts as 
transmitter and device 30 can act as receiver. Data in bit serial format is 
transported from the transmitter 20 to the receiver 30 via pin 26 the data 
connector 16 and then pin 36. A control connector 18 carries a control signal 
RTS/CTS asserted on pin 38 of the receiver to pin 28 of transmitter. 

The production of RTS/CTS on the data connector by the receiver and the 
response to RTS/CTS in the transmitter are controlled by software. 

The basic usage of RTS/CTS is conventional in that it means "flow 
on/off" when set active/inactive. The production of and response to RTS/CTS is 
not conventional and is controlled by a programmed processors in the receiver 
and transmitter. 
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It is also important for the present invention, as will become more clear 
presently, for the transmitter to be aware of packet boundaries. The 
transmitter gets the packets from some higher software layer. This other 
software layer could frame the packet or put it in a certain location so that the 
transmitter always knows the packet boundaries (or at least the packet start). 
Alternatively the packet length could be looked up in the packet, in the same 
way that the receiver does it and the transmitted bytes counted. 

Preferred Embodiment 

The flow control between transmitter and receiver is handled packet 
wise. The detection of the rising edge of RTS/CTS allows the transmission of 
only one packet. The receiver de-asserts the RTS/CTS inactive once the packet 
header has been received. The transmitter is not allowed to transmit the next 
packet until detection of another rising edge of the RTS/CTS signal. The flow 
control handling is illustrated in Figure 3. When the RTS/CTS goes inactive the 
transmitter completes transmission of the current packet. When RTS/CTS goes 
from inactive to active this signals the transmission of the next single packet. 

Referring to Fig. 3, RTS/CTS goes active at time T r There is a latency t x 
for detection of the rising edge at the transmitter. The transmitter detects the 
rising edge at T 2 . The transmitter takes t 2 to transmit the packet header and 
starts transmitting the rest of the packet at T 3 which takes t 3 . The transmitter 
finishes transmitting the packet at T 5 . There is a latency t 4 in the receiver 
detecting the transmitted packet header and this detection occurs at T =T +t , 

4 3 4 

and RTS/CTS goes inactive. 

The receiver puts RTS/CTS inactive after each and every packet header is 
received. The receiver then checks there is enough room for the next packet 
before putting RTS/CTS from inactive to active. The transmitter sends a single 
packet then waits for the RTS/CTS inactive-active transition (rising edge) before 
transmitting the next single packet. Thus transmission is packet wise and 
enabled by the CTS/RTS inactive-active transition. 
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f) start transmission of a single packet in response to detection of RTS/CTS 
active. 

g) go to a). 

The determination could be done as follows. The transmitter has a 
counter which maintains a count C of bits/bytes transmitted. The counter is 
reset to zero at the start of a packet. The transmitter continues to transmit 
until c = N'-l, then stops transmitting. 

Step b) is optional. Each falling edge (Active to Inactive) followed by a 
rising edge (Inactive to Active) of RTS/CTS may indicate that a packet should be 
transmitted or alternatively, each rising edge (Inactive to Active) of RTS/CTS 
may indicate that a packet should be transmitted. The CTS input of the 
transmitter causes an interrupt on each level change or, alternatively, only on 
the rising edge. 

For an already started packet the RTS/CTS level change won't cause any 
effect (transmission is continued whatever happens as the receiver has 
indicated by a "flow on" level that it can receive the max. packet size). 

Embodiment 2 

When the RTS/CTS goes low the transmitter completes transmission of 
the current packet. When RTS/CTS goes from inactive to active this signals the 
transmission of the next packet. 

The receiver monitors the remaining memory and an alert is created 
when the remaining memory falls below some threshold and is reset when the 
available memory rises above the threshold. The receiver puts RTS/CTS inactive 
only when there is an alert AND after a packet header has been received. That 
is, instead of changing RTS/CTS from active to inactive after every packet 
header is received as in the preferred embodiment, the transition only occurs 
when there is a risk of overflow. The transmitter would continuously send 
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active. 
7. go to 1) 

The determination could be done as follows. The transmitter has a 
counter which maintains a count C of bits/bytes transmitted. The counter is 
reset to zero at the start of a packet. The transmitter continues to transmit 
until C = NM, then stops transmitting. 

For an already started packet the RTS/CTS level change won't cause any 
effect (transmission is continued whatever happens as the receiver has 
indicated by a "flow on" level that it can receive the max. packet size). 

In the preceding embodiments, there is a step of detecting when a 
predetermined portion (header of size n) of the next packet has been received is 
used to put RTS/CTS inactive. Although an example of a predetermined portion 
is given (header) this is not critical. 

Whilst endeavouring in the foregoing specification to draw attention to 
those features of the invention believed to be of particular importance it should 
be understood that the Applicant claims protection in respect of any patentable 
feature or combination of features hereinbefore referred to and/or shown in the 
drawings whether or not particular emphasis is placed thereon. 
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receive a data packet; and 

allowing transmission of a data packet from the transmitter to the 
receiver if there is enough available memory and preventing transmission of a 
data packet from the transmitter to the receiver if there is not enough available 
memory. 

7. A receiver, for receiving packet data from a transmitter, comprising: 
an output for issuing flow control signals to the transmitter; 

an input for receiving data from the transmitter; 

a memory for storing data received from the transmitter; 

second detection means for detecting when a first portion of a packet has 
been received; and 

flow control signal means for providing a flow control signal on the 
output in response to said second detection means. 

8. A receiver as claimed in claim 7, wherein the flow control means 
provides a second flow control signal, stopping the transmitter from 
transmitting the next data packet, in response to the second detection means. 

9. A receiver as claimed in claim 7 or 8, wherein the second flow control 
signal is provided independently of the availability of the memory and once per 
packet. 

10. A receiver as claimed in any one of claims 7 to 9, additionally 
comprising 

first detection means for detecting that the memory has enough space to 
store the next packet to be received, wherein the flow control signal means 
provides a first flow control signal, enabling transmission of the next packet, in 
dependence upon the first detection means. 

11. A receiver as claimed in claim 10, wherein the first detection means 
detects for every packet that the memory has enough space to store the next 
packet to be received and the flow control signal means provides a first flow 
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